home *** CD-ROM | disk | FTP | other *** search
/ NOVA - For the NeXT Workstation / NOVA - For the NeXT Workstation.iso / Newsletters / GEnieUnixNews / unxnl-04.90 < prev    next >
Text File  |  1992-12-27  |  14KB  |  312 lines
  1.  
  2.           _ __  _   _ __ _ __
  3.          // /  //| // || \\|     N E W S
  4.         //_/  // |//  ||  |\\    Vol 1, Issue 5 - April 1990
  5.          R o u n d T a b l e
  6.  
  7.    Items of interest to participants of the GEnie Unix RoundTable
  8.  
  9.       The RoundTable SysOps are:
  10.       Dave Weinstein......OLORIN     Brian Riley.........DELPHI
  11.       Gary Smith..........GARS       Chris North-Keys....HARP
  12.       Rick Mobley.........LRARK    All Unix SysOps.....UNIXSYSOPS$
  13.    We strongly encourage you to contact any or all of us if you have -ANY-
  14.  comments or suggestions. This is -YOUR- RoundTable. We are here to make
  15.  your participation as pleasant and beneficial as possible.
  16.  
  17.  ED: editor notes (modularity)
  18.  --
  19.    If someone should ask you,"Why is *nix in all those little chunks of code
  20. instead of one nice, big monolithic program ?", tell them it is because the
  21. creators of Unix wanted their 'child' to emulate life, not Sherman tanks. I
  22. don't know if that is really a underlying reason, but it certainly seems so.
  23. When I take a drink of water I usually take a modular approach. ie: take 
  24. glass, open tap, place glass under tap, fill glass, turn off tap, raise glass
  25. to lips, drink. Now,I have drunk straight from a garden hose, and let me tell
  26. you that approach is messy. It accomplishes the same purpose, but it leaves a
  27. lot to be desired in the way of style.
  28.  
  29.    So it also is in Unix.  Small modular pieces  molded to create a homogenous
  30. product, each seperate, seemingly miniscule task combining to accomplish large
  31. tasks.  The analogy of a jigsaw puzzle can be made;  with one piece not having 
  32. any special significance, yet the puzzle is lacking without it. 
  33.  
  34.    This month's  newsletter is also the result of several  independent contri-
  35. butions.  It seems particularly appropriate that so many pieces came from many
  36. different sources,  since it resulted in our first  (almost)  theme or concept 
  37. newsletter.  The  common thread running throughout most of this month's digest
  38. is scripts, starting with Mike Nolan's column. 
  39.    We hope you enjoy. Gars
  40.  
  41. BEGINNERS PERSPECTIVE: Mike Nolan looks at scripts in his second installment.
  42. ---------------------  
  43.  
  44. Uncorking unix
  45. by Mike Nolan
  46.  
  47. "Getting Started in Shell Programming"
  48.  
  49. Unix is by far the most powerful operating system I've ever worked with.
  50. However, there are always things it doesn't do that I need, either to help
  51. with a particular problem or because I am used to having it on other systems.
  52.  
  53. It is often possible to add these capabilities by writing a 'shell script'.
  54. To do this, it is helpful to have some idea what a shell is and how it works.
  55. What follows is *my* explanation of the unix shell, which differs some from
  56. other definitions I have read.  These other definitions may be more
  57. technically accurate than mine, as I am trying to simplify as much as possible.
  58.  
  59. The unix operating system may be described as consisting of a large number of 
  60. programs collectively referred to as the 'kernel'.  These are programs which 
  61. the average user doesn't see or interact with very much.  In between the kernel
  62. and the user is another program which responds to user requests.  This program
  63. is the shell.
  64.  
  65. Actually, there are at least three shells used on unix systems.  Virtually 
  66. every unix system has the "Bourne shell", most have the "C shell", and an 
  67. increasing number have the more recent "Korn shell".  (I only have the 
  68. Bourne and the C shell on my system.)
  69.  
  70. These shells have many things in common.  All of them respond to user requests
  71. in three ways:
  72.  
  73. 1.  By performing the task directly.
  74. 2.  By passing the task on to the kernel, in one or more steps.
  75. 3.  By starting up one or more additional programs to perform the task.
  76.  
  77. Most requests involve more than one of these responses.
  78.  
  79. When the shell starts up another program, this program usually runs 
  80. independently of the shell program and is referred to as a 'subshell'.
  81. It is even possible that the subshell will be a *copy* of the original shell!
  82.  
  83. A 'shell script' is nothing more than a file which contains one or more 
  84. requests to be passed on to a shell.  Shell scripts range from simple one-
  85. liners which are in a script file just to avoid retyping frequently 
  86. used commands to complex groups of commands in which the later commands are 
  87. chosen based on the results of earlier commands.  Shell scripts are, in fact, 
  88. a type of programming language.
  89.  
  90. Shell scripts may be written specifically for each of the shells, but are
  91. most commonly written for the Bourne shell, especially if the shell script is
  92. to be passed on to other users, as *EVERYBODY* has the Bourne shell.  The Korn 
  93. shell was designed to include *all* of the capabilities of the Bourne shell 
  94. and add more capabilities; many feel it will eventually replace the Bourne 
  95. shell completely.  
  96.  
  97. The C shell is substantially different from the Bourne shell, but will start 
  98. up a Bourne shell to run a shell script if the first character of the script
  99. is *ANYTHING* other than a pound sign (#).  Many scripts have a colon (:) as 
  100. the only thing on the first line just to make sure that they are running on a 
  101. Bourne shell instead of a C shell.  A colon is a 'null' command in the Bourne
  102. shell, meaning it does nothing, so it won't mess up the Bourne shell.
  103.  
  104. As an example of a simple script which saves me from retyping a frequently
  105. used command, I offer the following script, which I call 'count'
  106.  
  107. ls -l $1 | cut -c25-31|awk '{s += $1} END {print s " bytes"}' -
  108.  
  109. This script gives a total count on the number of bytes in a directory, or
  110. in a group of files in the directory.  This script makes use of two very
  111. important ingredients:
  112.  
  113. 1.  Pipes or pipelining of input and output from one program to another.
  114.  
  115. 2.  Information passed to the script by the user at the time the script is
  116.     started, by including it on the command line.  This information can vary
  117.     from one time the script is executed to another.
  118.  
  119. Pipelining is best described by giving a visual example of the script 'count':
  120.         __        __    __        __ 
  121.           \______/        \______/  
  122.      ls    ______   cut    ______    awk 
  123.         __/      \__    __/      \__  
  124.  
  125. The first command ,'ls', lists the directory (or possibly only some of the 
  126. files in the directory.)  This information is passed along as the input to the
  127. second program, 'cut', which eliminates all information other than columns 25 
  128. through 31 (which contains the size of each file listed by ls), and then passes
  129. this information as the input to the third program, 'awk'.  Awk is a program 
  130. which, among other things, can do arithmetic on the input provided it, and in 
  131. this case it adds up a string of numbers (file sizes) and gives the 
  132. total as its output, which is then displayed on the screen.
  133.  
  134. When the 'count' script is executed, the shell starts up the 'ls' command,
  135. passes the output it generates on to the 'cut' command, and then passes
  136. that output along to 'awk'.  In fact, ls, cut, and awk are all running
  137. at the same time, in three separate subshells, with cut patiently waiting
  138. for ls to pass it output, processing it, and then passing it along to awk,
  139. which also sits patiently waiting.  [A *fourth* shell is also created.  It is 
  140. another copy of the Bourne shell, and actually process the script file.]
  141.  
  142. Pipelining is related to a more complicated process called redirection, which
  143. will be the subject of a future column.
  144.  
  145. The other tool demonstrated in the 'count' script is the passing of information
  146. from the command line to the script.  The shell interprets *all* input to it
  147. as consisting of a command, followed by a series of parameters, generally
  148. separated by a space or tab.
  149.  
  150. The '$1' in the ls command refers to the first parameter *after* the command
  151. itself.  If you type in
  152.  
  153.     count *xyz
  154.  
  155. then 'count' will only consider files that end in 'xyz'.  Parameters passing
  156. is more complicated than it appears, and will be dealt with more completely
  157. next month. 
  158.  
  159. Next month I'll also talk about how a shell script can keep track of 
  160. information within it and pass this information on to subshells.
  161.  
  162. Sub: New Unix RT SysOp
  163. ----------------------
  164. Yes, there has been another changing of the guard. Christopher Cilley was not
  165. able to keep his other commitments and still contribute to the maintenance of
  166. the GEnie  Unix  RoundTable as much as desired.  We wish Christopher well and
  167. thank him for his efforts on our behalf.
  168.  
  169.   Stepping in to replace Christopher is Brian Riley. Many of you already know
  170. Brian from his contributions the the GEnie Unix RoundTable as a user. It is a
  171. priviledge to welcome Brian as the newest member of your Unix support team on
  172. GEnie.  Brian's Username: DELPHI
  173.  
  174. WHO : Meet Brian Riley
  175. ---
  176.    Brian is a 28 year old computer technician currently working in
  177. the Philadelphia area. He learned UNIX on an AT&T 3B2/300 running
  178. UNIX SVR 2.02, in 1985. Since then he have worked with SVR 2.02 -
  179. 3.1.1, CTIX (Convergent Technologies UNIX) 5.0 - 5.3, and 3B1 UNIX
  180. 3.0 - 3.51m. Brian currently owns a 3B1 and an AT&T PC6300 (with
  181. enhancements) and 3 other computers. He programs in C (UNIX & DOS),
  182. and is learning Pascal and Assembler. He also enjoy Fantasy and Science
  183. Fiction books and Advanced Dungeons & Dragons. :)
  184.  
  185. CONTEST WINNER :
  186. --------------
  187.  
  188. From:   OLORIN                          David H. Weinstein
  189.  
  190. To:     M.NOLAN                         Michael E. Nolan
  191.  
  192. Sub: Unix RT Upload Contest
  193.  
  194. Congratulations! As the winner of the February-March Unix RT Upload
  195. Contest, you are entitled to one day of your choice free of charge
  196. in the Unix RoundTable (and the Unix RoundTable alone). For us
  197. to award you your prize, we will need your GEnie User Number and the
  198. day you wish to receive free of charge.
  199.  
  200. --Dave Weinstein
  201.   
  202. If you wish to be the recipient of this letter and enjoy some free access
  203. time on GEnie, all you have to do is start sharing your public domain
  204. files. Non-prime time uploads are free time themselves - so share !
  205.   
  206.  
  207. delete  alias unerase set from Dave Weinstein (OLORIN)
  208. ------
  209.  
  210.   Most microcomputer users are familiar with the "unerase" family of
  211. utilities. But the tricks which make it possible to restore an erased
  212. file from a single-tasking system do not work on multi-user, multi-tasking
  213. operating systems. The following are a few C-Shell aliases I use to keep
  214. from accidentally erasing too much of my work.
  215.  
  216.   alias   erase       "/bin/rm"
  217.   alias   rm          "mv \!* ~/.rm"
  218.   alias   dead        "ls ~/.rm"
  219.   alias   restore     "mv ~/.rm/\!* ./"
  220.   alias   purge       "/bin/rm -rf ~/.rm; (cd ; mkdir .rm)"
  221.  
  222. Usage of these aliases is fairly straightforward. Be sure to have created
  223. the directory ~/.rm before using them.
  224.  
  225. FAST and NASTY, DOWN  and  DIRTY:  quick  fix scripts that do something
  226. --------------------------------
  227.  
  228. This script first appeared in UnixWorld Vol. V, No. 8. It displays users
  229. from the /usr/passwd file, and has filters to only show what you want.
  230.  
  231. #----cut here----
  232. :
  233. # users List all valid system users
  234. # Author: Wendell Holmes, 1987
  235. #
  236. sed s/:.*//g /etc/passwd |
  237. while read user
  238. do
  239.     if [ -n "$user" ]
  240.     then
  241.         case $user in
  242.         root   ) ;;
  243.         sysadm ) ;;
  244.         bin    ) ;;
  245.         asg    ) ;;
  246.         sysinfo) ;;
  247.         network) ;;
  248.         lp     ) ;;
  249.         dos    ) ;;
  250.         news   ) ;;
  251.         cron   ) ;;
  252.         uucp   ) ;;
  253.         nuucp  ) ;;
  254.         *      ) echo $user ;;
  255.         esac
  256.     fi
  257. done
  258.         
  259. TODAY IS ?.... In honor of our script theme, here's a second handy one.
  260. --------       This one from Rick Mobley (LRARK) makes quick work out of
  261.                determining the current day when glancing at the calendar.
  262.                
  263.   Thought you could use a neat script for the Newsletter. Here is one that 
  264. uses terminfo instead of termcap and highlights the current day of the week. 
  265. I don't remember where or when I got it, but it comes in very handy.
  266.   Rick
  267.  
  268. #----cut here----
  269. :
  270. # @(#) today  Display calendar highlighting today
  271. # Author: Mathieu Federspiel
  272. #
  273. # Get date in the form produced by cal,
  274. # that is, removing any leading zero:
  275. day=`date '+%d' | sed 's/0\([123456789]\)/ \1/'`
  276. month=`date +%m`
  277. year=`date +%y`
  278. #
  279. # Store start and end stand out terminal codes,
  280. # translating any possible "&" to "=":
  281. smso=`tput smso | tr "&" "="`
  282. rmso=`tput rmso | tr "&" "="`
  283. #
  284. # Get calendar, add space to line, insert codes,
  285. # and translate "=" back to "&":
  286. cal $month $year | sed "s/^/ /" |
  287. sed "3,\$s/ ${day}/ ${smso}${day}${rmso}/" |
  288. tr "=" "&"
  289.  
  290.   --------
  291.    REMINDER - This newsletter is being sent to you 'by request'. If you do
  292.  not wish to keep receiving it, e-mail a stop notice to GARS. On the other
  293.  hand, we would very much appreciate it if you would pass the word that we
  294.  do distribute this item near the tenth (10th) of each  month to anyone on
  295.  GEnie who requests it, and will gladly add any name that is requested via
  296.  the same route... e-mail to GARS.
  297.    P L E A S E  also remember contributions are most welcome. Please e-mail
  298.  items and/or suggestions to GARS.
  299.  
  300.  (EOF)
  301.  
  302.  Trademark and Copyright notices:
  303.  Unix is a Trademark of  AT&T, GEnie, LiveWire, and RoundTable are Trademarks
  304.  of General Electric Information Services  Company,  Xenix is a Trademark  of
  305.  Microsoft  Corporation, UnixWorld is a Trademark of McGraw-Hill.
  306.  
  307. The contents of this newsletter are copyright (c) 1990 and may be copied whole
  308. or in part only if  original  credit is included. The GEnie UNIX RoundTable is
  309. not affiliated with AT&T.
  310. ay be copied whole
  311. or in part only if  original  credit is included. The GEnie UNIX RoundTable is
  312. not